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ABSTRACT 


United  States  Na\’3’  gas  turbine  ships  are  in  need  of  casualty  control  system  updating 
to  reduce  demanding  conditions  on  engineering  watch  standers,  to  increase  equipment 
longevity,  and  reduce  operating  costs.  This  thesis  presents  a  baseline  computer-based 
expert  system  controller  concept  developed  for  the  critical  casualty  control  problem  of 
gas  turbine  compressor  surge.  The  controller  design  rests  on  the  building-block  com¬ 
ponents  of  real-time  gas  turbine  simulation  and  compressor  surge  characterization, 
which  are  discussed.  The  logic  and  rules  for  the  expert  system  design  are  presented,  as 
is  a  dynamic  investigation  of  the  expert  system  diagnostic  performance. 
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I.  INTRODUCTION 


With  today's  U.S.  Navy  committed  to  gas  turbine  propulsion,  as  evidenced  by  five 
classes  of  ships  having  General  Electric  LM-2500  engines,  the  need  has  arisen  for  im¬ 
provements  to  these  power  plants  to  ensure  their  continued  effective  operation.  In 
particular,  engineering  w^atchstanders  and  operators  on  these  various  platforms  often 
work  under  demanding,  stressful  conditions  which  make  it  difficult  to  effectively  and 
quickly  diagnose  potential  casualties.  Further,  these  often  require  rapid,  precise,  and 
spontaneous  corrective  action.  A  recent  study  conducted  for  the  Na\7  Personnel  Re¬ 
search  and  Development  Center  found  that  personnel  were  no  longer  able  to  fulfill  the 
growing  demands  imposed  upon  them  in  their  roles  as  operators  of  gas  turbine  propul¬ 
sion  units  [Ref  1:  p.203].  Their  greatest  assistance  needs  were  found  to  be  in  the  areas 
of  fault  diagnosis  and  in  the  determination  of  proper  corrective  responses.  The  study 
went  on  to  suggest  that  these  two  areas  of  difficulty  may  be  effectively  handled  by  the 
combined  use  of  automation  and  computer  expert  systems.  An  improved,  automated 
expert  system  casualty  control  system  would  not  only  reduce  the  demanding  burdens  on 
the  operators,  but  would,  for  the  same  reasons,  additionally  increase  equipment  longev¬ 
ity  and  reduce  overall  operating  costs. 

Developing  a  marine  gas  turbine  expert  system  capable  of  casualty  control  capabil¬ 
ities  (that  is,  able  to  correctively  diagnose  severe  machinaiy'  degradation  and  eliminate 
or  minimize  potential  damage,)  is  a  multifaceted  project,  undoubtedly  requiring  a  vast 
amount  of  time  and  expertise.  Before  undertaking  such  a  monumental  task,  the  feasi¬ 
bility  of  such  a  system  should  be  successfully  demonstrated.  One  facet  of  the  turbine 
casualty  control  problem  is  the  problem  of  compressor  surge.  In  support  of  this  ap¬ 
proach,  a  system  validation  was  addressed  by  testing  an  expert  system  surge  casualty 
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control  design  on  a  low  power  gas  turbine  plant.  The  low  power  gas  turbine  test  bed 
was  a  critical  part  of  the  baseline  casualty  control  expert  system  as  it  was  assumed  to 
provide  half  the  system  input  data  through  direct  measurements.  The  remaining  system 
inputs  were  provided  by  a  real  time  simulator,  which  was  modelled  after  the  plant. 
Comparison  of  the  real  and  simulated  plant  data  formed  the  basis  for  the  expert  system 
diagnosis.  Consequently,  in  order  to  achieve  a  fully  competent  controller,  the  required 
real  time  simulator  must  be  accurate  and  reliable  over  the  gas  turbine's  entire  operating 
range.  Unlike  data  trends  or  plots  commonly  used  in  steady  state  condition  monitoring 
applications,  the  justification  of  an  accurate  real  time  simulator  lies  in  the  fact  that  naval 
gas  turbine  vessels  predominately  operate  in  a  dynamic,  non  steady  state  mode  [Ref  2: 
pp.286-287].  A  control  scheme  was  also  required  to  utilize  the  output  diagnostic  infor¬ 
mation  for  proper  casualty  control.  Several  schemes  to  this  are  presented  below,  even 
though  this  was  not  an  important  part  of  the  work  presented. 

An  important  element  of  the  baseline  expert  system  casualty  control  system  was  the 
software  utilized.  The  construction  of  an  expert  system  was  simplified  by  the  use  of  a 
user  friendly  expert  system  shell,  such  a  tool  is  NASA's  "C"  Language  Production  Sys¬ 
tem  (CLIPS)  [Ref  3:  p.lj.  One  of  the  appealing  features  of  CLIPS,  and  all  expert  system 
programs,  was  its  adaptibility.  For  example,  rather  than  having  to  construct  entirely 
new  software  when  a  problem  expands  or  takes  on  new  dimensions,  expert  system  soft¬ 
ware  written  to  solve  one  particular  problem  can  be  easily  supplemented  to  accommo¬ 
date  additional  constraints.  Therefore,  by  successfully  demonstrating  the  capability  of 
a  baseline  expert  control  system  for  one  particular  casualty,  as  in  the  present  study,  the 
feasibility  of  a  multiple  casualty  expert  control  system  is  realized  through  this  expert 
system  language  adaptability  feature. 
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II.  EXPERT  SYSTEM  BACKGROUND 


The  specialized  field  of  expert  systems  has  developed  from  the  Artificial  Intelligence 
(A.I.)  branch  of  Computer  Science.  Specifically,  this  branch  deals  with  expanding  a 
machine's  ability  to  perceive  and  reason,  or  accomplish  tasks  that  appear  to  require  in¬ 
telligence  [Ref  4:  p.l].  Expert  systems  are  computer  programs  that  solve  complex, 
real-world  problems  which  require  significant  human  expertise  to  interpret  and  solve. 
The  solution  of  these  involved  problems  is  accomplished  by  the  computer  program's 
ability  to  simulate  human  reasoning  and  arrive  at  similar  conclusions  or  solutions  as 
would  experts  in  the  field  which  the  problem  exits.  The  program's  expert  reasoning  ca¬ 
pability  is  largely  accomplished  through  utilizing  a  vast  body  of  knowledge  pertaining 
to  the  area  of  interest,  and  ranging  from  general  to  highly  specific  information.  Gener¬ 
ally  speaking,  an  expert  system  consists  of  the  following  three  parts  [Ref  5:  p.2]: 

1.  A  knowledge  base  consisting  of  facts  and  heuristics  associated  with  the  problem. 

2.  An  inference  or  reasoning  procedure  for  controlling  knowledge  information  flow, 
by  utilizing  that  information  to  draw  conclusions, 

3.  A  working  memoiy  or  data  base  for  data  and  problem  status  histoiy. 

The  facts  within  the  knowledge  base  are  a  commonly  known,  widely  agreed  upon 
collection  of  information;  while  the  heuristics  are  rules-of-thumb  known  only  by  the 
"experts",  obtained  through  expertise  in  the  field  of  interest.  Generally  speaking,  the 
larger  and  more  complex  expert  system  knowledge  bases  are,  the  more  they  are  capable 
of  solving  large,  more  complex  problems.  Representation  of  a  simplified  expert  system 
structure  is  shown  in  Figure  1. 
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Figure  I.  Expert  System  Components  and  Information  Flow  Direction 


Three  fundamental  characteristics  distinguish  an  expert  system  from  conventional 
programs.  First,  while  conventional  programs  make  no  distinction  between  knowledge 
and  how  knoAvledge  is  used,  expert  systems  clearly  seperate  the  two.  Secondly,  expert 
systems  utilize  "inexact"  reasoning  or  information  that  may  not  be  one  hundred  percent 
true.  Lastly,  expert  systems  can  be  easily  amended  or  their  knowledge  base  increased 
through  incremental  modifications,  while  changes  to  conventional  programs  are  often 
painstaking  [Ref  6:  p.5].  This  last  feature  is  appealing  in  the  sense  that  an  expert  system 
used  to  diagnose  and  control  one  particular  casualty  can  easily  have  its  knowledge  base 
broadened  to  accommodate  further  casualties  added  to  the  systems  diagnostic  and  con¬ 
trol  menu. 

Although  all  expert  systems  consist  of  the  three  aforementioned  core  features,  expert 
systems  differ  from  one  another  in  the  choice  of  solution  direction,  which  is  a  function 
of  the  inference  mechanism.  Expert  system  problem  solving  techniques  fall  under  the 
following  categories:  forward  chaining,  backward  chaining,  forw'ard  and  backward 
processing  combined,  and  event  driven.  For  the  purposes  of  brevity,  only  forward  and 
backward  chaining  will  be  discussed  because  they  are  the  two  primary  problem  solving 
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methods.  Forward  and  backward  processing  utilize  a  combination  of  backward  and 
forward  chaining  to  solve  complex  problems,  and  event  driven  processing  is  very  similar 
to  forward  chaining. 

Before  discussing  the  differences  of  forward  and  backward  chaining  some  basic  ex¬ 
pen  system  terminology  should  be  understood.  As  discussed  earlier,  expen  system 
knowledge  bases  are  composed  of  facts  and  heuristics  provided  by  the  field  experts;  in 
expert  programming  language,  this  information  is  known  as  "rules",  and  input  or  created 
data  are  termed  "facts".  In  forward  chaining,  the  control  strategy  is  initiated  with  a  list 
of  facts  (or  data)  and  utilizes  rules  (from  the  knowledge  base)  to  arrive  at  a  possible 
solution  to  the  particular  problem.  Forward  working  systems  are  oftem  characterized 
by  being  initiated  by  a  small  number  of  facts  and  are  able  to  reach  a  large  number  of 
potential  conclusions.  A  simple  example  of  forward  chaining  is  given  below. 

1.  Car  won't  start  (Input  data) 

2.  If  car  won't  start,  then  batteiy  dead  (Rule  1) 

3.  If  batter}’ dead,  then  need  new  battery  (Rule  2) 

4.  Need  new  batter}’  (Conclusion) 

Forward  chaining  is  often  used  for  equipment  or  machinery  diagnostic  applications, 
and  was  used  in  the  production  of  the  present  gas  turbine  baseline  casualty  control  ex¬ 
pert  system. 

Rather  than  starting  with  data,  or  a  fact  list,  backward  chaining  commences  with  a 
particular  goal  or  solution  in  mind,  and  works  backwards.  From  existing  rules  it  is  de¬ 
termined  what  facts  are  necessar}’  to  obtain  the  particular  stated  goal.  Existing  facts  are 
then  checked  to  decide  if  the  goal  is  correct,  and  if  facts  are  not  available  the  user  is 
asked  to  answer  questions  to  generate  facts  and  obtain  a  conclusion  [Ref  7:  p.22].  An 
example  of  backward  chaining  is  given  below. 

1.  Need  new  battery’  (Hypothesized  Conclusion) 

2.  If  need  new  battery,  then  battery  is  dead  (Rule  1) 
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3.  If  battery  is  dead,  then  car  won't  start  (Rule  2) 

4.  If  car  won't  start,  then  need  new  battery  (Rule  3) 

5.  Will  the  car  start?  (Data) 

Just  as  some  problem  solving  techniques  work  better  in  certain  situations,  the  same 
holds  true  with  expert  systems;  in  some  applications  expert  system  utilization  is  infeasi¬ 
ble  or  impractical,  while  in  other  cases  the  problem  may  be  too  complex  or  involved  to 
be  handled  in  an  ordinary,  non-expert  system  manner.  The  potential  domain  of  expert 
system  utilization  is  rather  precise.  The  following  list  of  expert  system  characteristic 
criteria  should  be  met  prior  to  undertaking  development  [Ref  8:  p.6]: 

1.  Genuine  experts  exist  in  the  field 

2.  Existing  experts  are  much  better  than  amateurs 

3.  Skill  must  be  routinely  taught  to  amateurs/novices 

4.  Task  must  be  within  reason 

5.  Task  should  not  require  common  sense 

6.  Undertaking  should  have  sufficient  payoff  to  warrant  construction 

In  the  gas  turbine  arena  there  has  been  a  number  of  recent  expert  system  related 
developments  initiated  by  the  U.S.  military.  For  example,  in  order  to  improve  the  reli¬ 
ability  and  maintainability  of  gas  turbine  engines  in  the  United  States  Air  Force  inven¬ 
tory,  the  Air  Force  has  been  testing  a  new  knowledge-based  (expert  system)  diagnostic 
system  which  utilizes  gas  turbine  vibration  analysis  data  to  diagnose  rotor  dynamic 
faults.  The  diagnostic  concept  developed  was  successfully  demonstrated  on  a  test  rig 
when  the  integrated  system  with  its  implemented  diagnostic  logic  and  vibration  data 
aquisition  system  successfully  diagnosed  five  inputted  faults  including:  rotor  unbalance, 
misalignment,  rub,  increased  support  fexibility  and  accessory  vibration  [Ref  8:  p.7]. 
Additionally,  the  U.S.  Army  is  developing  an  expert  system  which  utilizes  forward  and 
backward  reasoning  to  diagnose  faults  in  a  twin  engine  gas  turbine  helicopter  power 


6 


train  from  instrument  panel  data  readings,  thereby  decreasing  the  evergrowing  workload 
demands  on  the  single  cockpit  pilot  [Ref  9:  p.l9]. 

The  Xavw  got  involved  in  a  shipboard  gas  turbine  condition  monitoring  project  in 
1974  concerned  with  reliability  of  monitoring  hardware,  which  had  to  improve  by  a  fac¬ 
tor  of  ten  before  the  system  could  be  used  as  an  effective  trouble  shooting  tool  [Ref 
10:  p.9].  In  the  last  decade,  however,  technology  and  controller-sensor  reliability  have 
substantially  increased.  Expert  system  tools  such  as  the  NASA/Johnson  Space  Center's 
'C'  Language  Production  System  (CLIPS)  are  currently  available.  CLIPS  is  a  user 
friendly,  forward  chaining  expert  system  computer  language  designed  for  writing  expert 
system  applications.  CLIPS  was  designed  for  portability,  as  it  may  run  on  a  range  of 
microcomputers  with  little  or  no  software  modifications  necessary.  CLIPS  can  be  easily- 
integrated  at  virtually  no  cost  to  external  systems,  and  was  found  to  be  quite  computable 
for  use  in  a  marine  gas  turbine  expert  control  system.  The  use  of  CLIPS  to  develop  a 
proper  expert  system  will  be  discussed  following  a  description  of  the  compressor  surge 
problem. 
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III.  COMPRESSOR  SURGE 


Rather  than  examining  a  vast  number  of  possible  engine  casualties,  attention  was 
focussed  on  one  particular  casualty  which  greatly  effects  the  entire  engine  if  not  detected. 
Compressor  surge  was  chosen  for  this  effort  because  of  its  relation  to  compressor  stall, 
since  stall  has  been  implicated  for  one  of  every  five  unscheduled  engine  removals  in  the 
LM-2500  gas  turbine  program  [Ref.  11:  p.l3].  However,  before  an  adequate  casualty 
control  expert  system  for  the  prevention  of  compressor  surge  can  be  developed,  a  clear 
understanding  of  the  surge  phenomenon  must  be  obtained.  Though  often  used  inter¬ 
changeably,  compressor  stall  and  surge  are  not  one  in  the  same.  Basically,  compressor 
stall  can  be  descibed  as  a  momentaty'  disruption  of  the  normal  air  flow  rate  through  the 
compressor,  while  surge  is  a  more  severe  form  of  stall.  During  surge,  air  flow  through 
the  compressor  undergoes  an  actual  reversal  in  flow  direction.  However,  the  mechanics 
of  surge  are  quite  involved  and  not  yet  fully  understood;  even  so,  stall  has  a  clear  me¬ 
chanical  relationship  to  surge  and  it  is  a  widely  held  belief  that  stall  may  initiate  a  surge 
condition  [Ref.  12:  p.ll3]. 

The  most  common  type  of  compressor  stall  is  known  as  rotating  stall.  Rotating  stall 
can  be  initiated  by  the  stalling  of  a  single  blade.  A  slight  distortion  or  uneven  distrib¬ 
ution  of  velocity  at  the  inlet  to  the  compressor  may  cause  a  blade's  incidence  angle  to 
increase,  changing  from  i  to  i'  as  shown  in  Figure  2. 


Figure  2.  Increased  Incidence  Angle 

At  some  increased  incidence  angle,  which  is  diificult  to  define,  flow  separates  from  the 
suction  side  of  the  blade  and  the  blade  stalls  [Ref.  13:  p.67].  The  stalled  blade,  due  to 
the  separated  flow,  then  creates  or  causes  an  area  of  retarded  or  blocked  flow  which,  in 
turn,  increases  the  incidence  angle  on  the  blade  adjacent  to  the  stalled  blade,  in  the  di¬ 
rection  opposite  of  blade  rotation.  The  retarded  flow,  however,  decreases  the  incidence 
angle  of  the  blade  next  to  the  stalled  blade  in  the  direction  of  rotation,  returning  it  to  its 
normal  angle  of  attack  and  restoring  flow  around  the  blade.  The  area  of  retarded  flow 
travels  from  blade  to  blade,  and  the  stalling  and  unstalling  action  propogates  within  the 
same  row  of  rotating  blades,  creating  the  condition  of  rotating  stall.  Serious  blade 
damage  may  result  if  the  loading  and  unloading  of  the  rotating  blades  approaches  the 
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blades'  natural  frequency.  The  rotating  or  propagating  stall,  as  it  is  sometimes  refered 
to  is  illustrated  in  Figure  3. 


Figure  3.  Rotating  Stall 


The  most  distinguishing  characteristic  between  rotating  stall  and  surge  is  the  air 
mass  flow  rate.  While  the  total  mass  flow  rate  during  a  rotating  stall  remains  relatively 
constant,  a  surge  condition  exhibits  an  oscillation  or  pulsation  of  the  air  flow.  A  widely 
accepted  theor>'  on  the  surge  phenomenon's  trigger  mechanism  is  lacking,  although 
many  contribute  it  to  rotating  stall  [Ref  12:  p.ll3].  What  the  experts  do  agree  on, 
however,  is  the  necessary  condition  for  surge;  that  being  a  positive  instantaneous  pres¬ 
sure  ratio/mass  flow  gradient,  which  for  a  normal  operating  compressor  is  negative.  This 
prerequisite  surge  condition  and  a  description  of  what  occurs  during  a  surge  cycle  can 
be  understood  by  examining  the  theoretical  compressor  curve  shown  in  Figure  4. 
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Figure  4.  Theoretical  Characteristic  Curve 

Consider  a  theoretical  valve  placed  in  the  delivery  line  of  a  compressor  running  at 
constant  speed.  As  the  valve  is  slowly  openned  from  zero  flow  (point  A)  the  pressure 
ratio  increases  to  a  maximum  (point  B).  Additional  increases  in  mass  flow,  achieved  by 
openning  the  valve  further,  result  in  a  falling  off  of  pressure  ratio  until  it  reaches  zero 
(point  C).  This  pressure  ratio  drop  is  caused  by  the  deviation  of  the  particular  air  mass 
flow  rate  from  the  design  flow  rate,  which  creates  air-blade  angle  missmatching,  and 
causes  a  decrease  in  compressor  efficiency.  [Ref.  12:  p.lll]. 

The  portion  of  the  curve  between  points  E  and  C  must  be  operationally  avoided 
because  of  the  much  severe  (negative)  slope  of  the  characteristic  curve.  In  this  region, 
pressure  ratio  drops  rapidly  with  only  a  slight  increase  in  air  mass  flow  rate  through  the 
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compressor.  Operating  along  this  portion  of  the  curve  would  result  in  a  condition 
known  as  compressor  choking. 

Normally,  the  compressor  would  operate  between  points  E  and  B,  where  the  slope 
is  negative  and  less  severe,  and  where  small  deviations  in  mass  flow  rate  do  not  cause 
drastic  pressure  ratio  movement.  The  negatively  sloped  operating  curve  dictates  an  in¬ 
crease  in  pressure  ratio  for  a  drop  in  air  mass  flow  rate  through  the  compressor. 

Contrarily,  when  operating  between  points  B  and  A,  where  the  characteristic  curve 
slope  is  positive,  any  decrease  in  the  flow  rate  will  result  in  a  decrease  in  pressure  ratio. 
This  action  can  be  seen  in  Figure  4,  by  running  along  the  curve  from  B  to  A  and  noting 
the  relation  between  flow  rate  and  pressure  ratio.  In  actual  (non  theoretical)  compressor 
operation,  however,  this  portion  of  the  curve  from  B  to  A  is  relatively  unusable  due  to 
the  surge  phenomenon.  As  shown  in  Figure  5, 


Figure  5.  Surge  Orbit 
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before  the  operating  point  is  able  to  move  down  the  positive  slope  portion  of  the  curve, 
the  mass  air  flow  rate  has  already  reversed  its  direction  through  the  compressor,  (moved 
from  B  to  F)  as  depicted  in  the  figure.  This  flow  reversal  can  be  explained  in  the  fol¬ 
lowing  manner.  Suppose,  for  example,  the  compressor  is  temporarily  fixed  at  point  D 
(Figure  4),  again,  noting  that  the  slope  of  the  characteristic  curve  in  this  region  is  posi¬ 
tive.  If,  while  operating  at  this  point,  a  decrease  in  mass  air  flow  is  experienced,  an  ac¬ 
companying  drop  in  pressure  ratio  or  delivery  pressure  would  occur  (as  expected  by  the 
curve).  If  at  that  instant,  though,  the  existing  pressure  immediately  downstream  of  the 
compressor  exit  did  not  fall  as  quickly  as  that  of  the  the  air  in  the  compressor,  then  the 
air  will  tend  to  take  the  path  of  least  resistance,  reverse  its  direction  and  flow  backwards 
through  the  compressor  -  in  the  direction  of  the  resulting  negative  pressure  gradient. 
This  reversal  in  flow  direction  causes  a  rapid  drop  in  the  pressure  ratio  (or  delivery- 
pressure),  which  creates  a  fall  in  the  pressure  downstream  of  the  compressor,  thus  re¬ 
turning  the  airflow  back  to  its  normal  direction  through  the  compressor.  The  surge  cy  cle 
is  now  in  a  position  of  repeating,  provided  the  operating  point  remains  on  or  is  influ¬ 
enced  to  the  positive  side  of  the  characteristic  curve,  and  the  delivery-  pressure  falls  at  a 
greater  rate  than  the  pressure  downsteain  of  the  compressor.  The  surge  cycle  (or  "orbit") 
described  above  is  illustrated  in  Figure  5. 

A  well  established  method  to  prevent  the  onset  of  surge  is  to  use  a  blow-ofr(pressure 
relief  recirculation)  valve  when  the  compressor's  back  pressure  exceeds  a  preset  limit. 
1  his  is  discussed  in  more  detail  in  Chapter  6,  but  it  is  not  a  simple  matter  to  implement 
in  practice.  1  he  need  for  rapid  control  to  recover  may  be  met  with  an  expert  system  that 
can  precisely  determine  the  onset  of  the  casualty  condition. 
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IV.  PLANT  DESCRIPTION 


The  test  bed  utilized  in  the  development  of  the  baseline  expert  surge  control  system 
was  the  gas  turbine  at  the  Naval  Postgraduate  School.  This  plant,  which  is  commonly 
used  for  gas  turbine  laboratory  experiments,  consists  primarily  of  a  Boeing  model  502-2E 
gas  turbine  engine  coupled  to  a  Clayton  17-300  water  brake  dynamometer.  The  test  bed 
is  illustrated  in  Figure  6. 


Figure  6.  Test  Bed  Installation 


The  Boeing  model  502-2E  gas  turbine  engine  is  rated  at  175  brake  horsepower  and 
consists  of  two  primary  sections:  a  gas  producer  and  a  power  output  section.  The  gas 
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producer  contains  a  single  stage,  single  entry’,  centrifugal  compressor,  two  cross  con¬ 
nected  through-flow  combustion  chambers,  a  single-stage  high  pressure  axial  flow  tur¬ 
bine  (HPT),  and  an  accessory  drive  section.  The  power  output  section  consists  of 
another  single  stage,  axial  flow,  free  power  turbine  (FPT),  reduction  gears  and  an  output 
shaft.  The  power  output  shaft  is  aerodynamically  coupled  by  a  duct  which  directs  the 
flow  of  gasses  from  the  HPT  to  the  FPT.  This  arrangement  allows  the  HPT  or  gas 
producer  to  be  controlled  more  or  less  independently  of  the  output  shaft  speed.  [Ref 
14:  p.l] 

The  output  shaft  is  mechanically  coupled  to  a  Clayton  17-300  water  dynamometer 
which  absorbs  the  power  generated  by  the  engine.  Power  absorbed  is  regulated  by  the 
quantity  of  water  allowed  in  the  dynamometer  shell.  This  absorption  action  is  achieved 
by  a  rotationg  impeller  attached  to  the  shaft  which  produces  a  torque  that  is  propor¬ 
tional  to  the  water  level  in  the  dynamometer.  The  greater  the  amount  of  water,  the 
greater  the  surface  area  acting  on  the  impeller,  and  the  greater  the  torque  and  power 
absorbed. 

The  gas  turbine  engine  has  two  control  modes;  a  marine  emulator  mode  and  a 
manual  mode.  In  both  modes  engine  control  is  divided  into  two  areas;  gas  generator 
control  and  load  control.  The  gas  generator  control  is  accomplished  primarily  through 
the  use  an  analog  flyball  governor,  which  dictates  the  motion  of  a  motor-driven  throttle 
positioner.  Required  input  to  the  flyball  governor  is  the  desired  gas  generator  speed, 
which  is  translated  to  fuel  flow  output.  The  load  control  is  a  digital,  proportional-plus- 
derivative  controller  which  regulates  the  amount  of  water  in  the  dynamometer  through 
manipulating  water  inlet  and  outlet  valves.  [Ref  15:  p.l 6].  Required  input  for  the  load 
controller  is  desired  dynamometer  speed. 

When  using  the  manual  control  mode  the  operator  simply  inputs  the  desired  gas 
generator  speed  and  the  desired  dynamometer  speed.  When  operating  the  engine  utiliz- 
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ing  the  marine  emulator  mode,  however,  the  operator  simply  inputs  the  desired 
dynamometer  speed  and  the  desired  load  or  propeller  pitch.  The  control  system  auto¬ 
matically  determines  the  gas  generator  speed  to  fit  the  desired  dynamometer  speed  and 
load.  Again,  the  desired  load  is  controlled  by  the  regulated  water  level  in  the 
dynamometer. 

Looking  at  the  Boeing  gas  turbine  power  plant  in  comparison  to  those  on  board 
Navy  gas  turbine  ships,  two  important  features  are  similar,  thus  enhancing  applicability 
of  the  baseline  expert  casualty  control  system.  These  two  similar  characteristics  are  the 
two  engine  control  systems  and  the  engines  component  configurations. 

The  marine  emulator  control  mode  is  similar  to  the  FFG-7  class  propulsion  control 
system,  shown  in  Figure  7. 


Figure  7.  Simplified  Propulsion  Control  System 
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On  the  FFG-7  class,  the  propulsion  control  system  (PCS)  can  control  the  gas  turbine 
engine  power  and  propeller  pitch  via  three  control  modes:  local  manual,  remote  manual 
or  programmed  control.  In  the  programmed  control  mode,  which  is  the  primary  oper¬ 
ating  mode,  gas  turbine  power  and  propeller  pitch  are  automatically  controlled  by  a 
single  control  lever.  Similarly,  the  NPS  marine  emulator  control  system  has  load  control 
capability,  (akin  to  the  propeller  pitch  system),  and  output  shaft  speed  control. 

The  other  characteristic  which  is  common  to  both  operating  plants  is  engine  com¬ 
ponent  composition.  Having  already  descibed  the  makeup  of  the  NPS  Boeing  model 
502-6A,  the  G.E.  LM-2500  gas  turbine  engine  has  a  similar  component  arrangement. 
Like  the  Boeing,  the  LM-2500  consists  of  a  two  major  sections;  the  gas  generator  and 
power  turbine.  The  gas  generator  portion  consists  of  an  axial  flow  compressor, 
combustor  and  a  high  pressure  turbine.  The  compressor  and  high  pressure  turbine  are 
connected  by  a  single  shaft,  (as  with  the  Boeing).  The  exhaust  gases  from  the  high 
pressure  turbine  are  directed  through  the  free  power  turbine,  with  no  mechanical  con¬ 
nection  existing  between  the  two  turbines,  again  similar  to  the  coupling  on  the  Boeing 
engine. 
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V.  REAL  TIME  SIMULATOR 


The  real  time  simulator  for  the  N.P.S.  Boeing  gas  turbine  engine  is  largely  the 
product  of  previous  work  conducted  by  faculty  and  students,  the  following  desciption 
of  the  real  time  simulator's  composition  is  primarily  a  brief  review  of  that  work.  A  more 
thorough  explanation  can  be  attained  from  [Ref  16].  An  understanding  of  the  me¬ 
chanics  behind  the  real  time  simulator  was  considered  important  due  to  the  thought  that 
a  similar  structured  simulator  could  be  constructed  for  the  LM-2500  gas  turbine  engine, 
and  because  the  real  time  simulator  is  such  an  integral  part  of  the  casualty  control  expert 
system. 

Requirements  for  the  real  time  simulator  were  accuracy  and  quickness.  These  two 
requirements  do  not  necessarily  complement  one  another,  because  a  simple  model  may 
be  quick,  but  have  questionable  accuracy.  It  was,  however,  felt  that  sufficient  accuracy 
could  be  attained  from  a  quasi-linear  model,  even  though  a  large  quantity  of  literature 
exists  on  the  incompatability  of  dynamic  gas  turbine  engines  and  linear  models.  In 
wrestling  with  the  nonlinear,  dynamic  environment  a  sequential  state  space  linearization 
technique  was  utilized  in  developing  the  model  of  the  engine.  The  procedure  utilized  is 
summarized  in  the  list  below.  [Ref  16] 

1.  Determine  the  nonlinear  relations  between  the  individual  components  inputs  and 
outputs  as  shown  in  Figure  S. 

2.  Linearize  the  models  of  each  component. 

3.  Create  an  overall  linearized  system  model  by  combining  the  linearized  components. 

4.  Test  the  model  accuracy  and  speed  with  simulated  system  performance. 
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Figure  8.  Cause  and  Effect  Plant  Model 


Component  modelling  was  accomplished  primarily  with  simple  algebraic  equations. 
Instantaneous,  non-dynamic  component  outputs  were  modelled  as  complete  quadratic 
functions  in  terms  of  input  variables,  with  instantaneous  constants  determined  exper¬ 
imentally  with  steady  state  data. 


^’c-^Qhp~  Qc)i-^G  (^•^) 

Components  with  considerable  time  lags,  such  as  shaft  rotor  and  combustor  were  mod¬ 
elled  with  rate  equations,  as  above.  The  dynamic  constants  in  these  equations  were  de¬ 
termined  from  dynamic  experimentation.  An  example  equation  for  a  non-dynamic 
variable  is  given  below:  [Ref  16) 
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Qc  —  +  cA(jP2  +  eP2+f 


(5.2) 


Component  output  equations  were  linearized  using  perturbation  analysis.  The  per¬ 
turbed  version  of  equation  (5.1)  is  as  follows: 

dNg  =  {dQHp-dQc)lJc  (5.3) 


Perturbations  were  defined  as: 


=  (5.4) 

Using  steady  state  operating  data,  linearization  points  were  established  in  order  to 
linearize  the  equations  in  terms  of  the  perturbed  values.  [Ref.  16] 

A  state  space  form  was  utilized  in  combining  the  linearized  component  model 
equations  to  create  the  overall  linear  system  model.  Through  numerical  and  physical 
experimention.  a  minimum  list  of  variables  or  states  were  determined  which  were  neces¬ 
sary  to  determine  the  dynamic  and  steady  state  operating  characteristics.  These  states 
were  found  to  be  shaft  speed,  gas  generator  speed  and  the  combustion  energy  state. 


X(l)  =  A'c 

(5.5) 

X{2)  =  A5 

(5.6) 

X{3)  =  E 

(5.7) 

Equally  important  as  the  states  in  attaining  a  desired  plant  performance  are  the  input 
variables,  these  were  selected  as  fuel  flow  rate  and  load  torque.  Since  establishing  the 
nonlinear  relation  between  the  states  and  inputs  is  too  complex  a  task,  the  dynamic  be¬ 
havior  of  the  plant  may  be  attained  through  a  series  of  linearizations  of  the  nonlinear 


20 


I 

I 

first  order  differential  equation  expressing  the  relation  between  the  states  and  inputs  as 
shown:  [Ref  16] 


k  =  Ax +  Bu 


(5.8) 


where: 


x  =  dX 


(5.9) 


u  =  dU 


(5.10) 


Expansion  of  equation  (5.8)  yields: 


dS(j 

^(1,1)  /1(1.2)  /1(3,1) 

6.\q 

*5(1,1)  5(1,2)' 

= 

^(2,1)  ^(2.2)  A{3,2) 

+ 

5(2,1)  5(2,2) 

cE 

/f(3,l)  /1(2,3)  /1(3,3) 

dE 

_5(3,1)  5(3,2)_ 

The  "A"  and  "B"  matrixes  were  attained  anal\  tically  by  utilizing  knowledge  of  the 
states  at  desired  linearization  points  and  using  the  quadratic  component  equations  to 
balance  the  turbine  to  steady  state  and  determine  the  remaining  plant  variables.  The 
attained  plant  variables  were  then  substituted  into  linearized  component  equations  to 
determine  matrix  entr}'  values.  A  set  of  matricies  was  established  for  the  entire  operating 
envelope,  to  reveal  how  the  plant's  linearization  varied.  The  B  matrix  was  found  to  be 
constant  and  curve  fits  were  conducted  to  establish  equations  for  the  A  matrix  elements 
in  terms  of  the  states  (gas  generator  and  shaft  speeds).  The  B  matrix  values  and  the  A 
matrix  equations  can  be  seen  in  the  real  time  simulator  program  contained  in  Appendix 
A.  [Ref.  16:  p.5] 

Testing  of  the  simulator  clearly  indicated  that  the  sequential  linearization  technique 
provided  a  better  response  then  the  single  linearization  method,  and  the  results  were 
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quite  good  when  compared  with  actual  data  when  tested  at  constant  gas  generator 
speeds  while  shaft  speed  was  varied.  To  estimate  computational  time  constraints  a  tim¬ 
ing  study  was  conducted  using  the  code  contained  in  Appendix  A.  Plant  input  values 
for  load  and  fuel  flow  rate  were  not  included  in  the  program  as  they  would  be  directly- 
input  into  the  program  through  a  "read"  statement  during  each  program  iteration.  Read 
time  was  assumed  to  be  negligible.  Using  a  32  bit  processor  a  100  second  simulated  run 
with  a  0.001  second  time  step  took  roughly  13  secords  or  0.13  seconds  of  computation 
time  for  each  second  of  simulation  time  (Ref  16:  p.6.]. 

In  order  to  test  the  expert  surge  control  system,  the  code  in  Appendix  A  had  to  be 
modified.  This  modification  included  changing  the  FORTRAN  code  to  C  code,  input¬ 
ting  values  for  load  and  fuel  flow  rate,  and  inserting  into  the  program  equations  to 
generate  the  compressor  discharge  pressure  and  compressor  air  mass  flow  rate  from  the 
state  values  at  the  time  of  interest.  When  considering  how  the  load  and  fuel  flow  values 
should  be  input,  the  thought  of  reading  the  two  values  from  a  data  file  was  ruled  out  due 
to  the  enormous  size  the  data  file  would  have  to  be  to  accommodate  even  a  simulated 
ten  second  run.  The  problem  was  handled  by  approximating  the  input  time  histories 
using  simple  linear  equations  derived  from  actual  dynamic  data  taken  off  a  strip  chart. 
Since  naval  gas  turbine  plants  do  not  operate  dynamically  at  constant  gas  generator 
(compressor)  speeds  when  operating  in  the  speed  control  or  power  control  mode,  the 
baseline  expert  surge  control  system  testing  should  be  accomplished  while  the 
compressor  was  in  a  dynamic  state.  This  testing  constraint  was  accomplished  by  var>'ing 
the  load  at  constant  power  turbine  speed.  This  arrangement  is  akin  to  the  speed  control 
mode  naval  gas  turbine  ships  operate  under  for  speeds  between  zero  and  ten  knots.  In 
this  speed  interval  (0-10  kts)  shaft  and  power  turbine  speed  is  held  constant,  and  ship 
speed  changes  are  accomplished  by  varying  the  propellor  pitch.  The  change  in  load  is 
satisfied  by  an  increase  or  decrease  in  gas  generator  speed. 
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The  equations  for  compressor  outlet  pressure  and  air  mass  flow  rate  were  required 
to  be  included  in  the  simulator  code  because,  along  with  compressor  speed,  they  are 
critical  variables  in  determining  the  compressor  operating  point  in  order  to  access  po¬ 
tential  surge  onset.  Equations  for  outlet  pressure  and  flow  rate  were  computed  using  a 
curve  fitting  technique  from  steady  state  taken  taken  over  a  wide  range  of  operating 
conditions.  The  non-normalized  equations  for  compressor  outlet  pressure  (psia)  and  air 
mass  flow  rate  (Ibm/sec)  are  given  below: 

P2  =  14.0[0.504  -  lAAXc  -1-  O.OI34.V5  +  1.81  A c]  (5.12) 

=  2.36[-0.176-f-  1.16.Vc  +  0.022(P2/14.0)]  (5.13) 

When  testing  the  modified  real  time  simulator  code  with  strip  chart  data,  dynamic 
data  under  constant  shaft  speed  and  load  varying,  a  scaling  factor  error  was  encount¬ 
ered.  and  the  time  step  had  to  be  changed  from  0.001  to  0.000368  which  yielded  ver}- 
good  agreement  with  recorded  data  measurements.  On  a  16  bit  processor,  using  an  op¬ 
timizing.  turbo  C  compiler,  a  simulated  ten  second  run  took  47  seconds  of  computation 
time.  Or  for  each  second  of  simulated  time  4.7  seconds  of  computation  time  was  re¬ 
quired.  The  modified  C  language  version  of  the  real  time  simulator  code  can  be  found 
in  Appendix  B. 
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VI.  EXPERT  SYSTEM  DESIGN 


Having  been  introduced  to  expert  systems,  the  surge  phenomena,  the  Boeing  502-6 
gas  turbine  engine,  and  the  background  of  the  Boeing  real  time  simulator,  the  framework 
of  the  baseline  expert  system  to  diagnose  and  prevent  compressor  surge  onset  can  be 
discussed.  The  basic  principle  of  the  system  is  illustrated  in  Figure  9. 


Output 


Figure  9.  E.xpert  System  Frame^^ork 
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As  illustrated,  the  same  inputs  were  provided  to  both  the  engine  (or  plant)  and  the  real 
time  simulator  (or  model).  Output  was  received  from  the  plant  and  model  by  a  central 
processor  (or  microcomputer).  There,  the  two  sets  of  data  were  massaged  into  identical 
indicators  and  tolerance  windows  were  applied  to  the  model  indicators.  The  data  sets 
were  then  compared  and,  based  on  deviation  analysis,  a  control  decision  was  reached. 
With  these  basic  functions  in  mind  a  five  step  approach  was  used  in  developing  the 
anti-surge  casualty  control  expert  system,  as  listed  below: 

1.  Select  key  engine  health  indicators,  including  measured  and  calculated  parameters. 

2.  Determine  and  apply  indicator  tolerances. 

3.  Compare  key  engine  health  indicators  with  the  same  parameters  provided  by  the 
real  time  simulator,  and  determine  respective  health  indicator  deviations. 

4.  Evaluate  and  analyze  the  indicator  deviations. 

5.  Based  on  the  deviation  analysis  determine  corrective  control  action. 

The  remainder  of  this  chapter  is  devoted  to  discussing  the  composition  of  these  steps  and 
their  integration  into  the  total  expert  system  package. 

As  was  described  in  Chapter  Three,  the  compressor  surge  phenomena  is  a  complex 
condition,  not  yet  fully  understood.  Nevertheless,  there  was  one  facet  of  the  surge  con¬ 
dition  discussed  earlier  that  the  experts  did  agree  on,  that  being  the  principle  condition 
necessary  for  surge  onset,  namely,  a  positive  instantaneous  pressure  ratio'mass  flow 
gradient.  In  other  words,  if  the  compressor  operating  point  lies  on  the  positive  portion 
of  the  compressor's  characteristic  curve  (at  a  given  compressor  speed)  the  main  prereq¬ 
uisite  for  surge  has  been  met.  The  key  surge  indicators,  therefore,  were  chosen  to  be 
those  parameters  which  established  position  on  the  standard  compressor  map;  namely, 
compressor  speed,  air  mass  flow  rate  through  the  compressor,  and  compressor  inlet  and 
discharge  pressures;  which  together  determine  pressure  ratio.  A  hypothetical  compressor 
performance  map  is  shown  in  Figure  10. 
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Figure  10.  Hypothetical  Compressor  Performance  Map 

It  should  be  noted  tliat  standard  correction  factors  for  temperature  and  pressure  have 
been  applied  to  accommodate  compressor  operations  under  varying  conditions.  It  is 
conceivably  possible  for  a  compressor  not  to  go  into  surge  immediately  when  the 
compressor's  operating  point  has  crossed  the  surge  line  as  shown  in  Figure  10  due  to  a 
particular  engine's  air  flow  swallowing  capacity  achieved  by  components  downstream 
of  the  compressor  (thus  maintaining  the  required  negative  pressure  gradient  through  the 
compressor).  However,  under  normal  design  conditions  it  is  simply  a  matter  of  time 
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before  a  reduction  in  air  mass  flow  rate  is  introduced  and  the  related  pressure  reduction 
causes  the  pressure  gradient  to  shift,  resulting  in  the  undesirable  flow  reversal.  Further, 
this  is  why  compressors  normally  operate  in  the  negative  slope  regions  of  their  charac¬ 
teristic  curves  (figure  4),  where  a  decrease  in  air  mass  flow  rate  is  accompanied  by  a  rise 
in  delivery  pressure,  thus  ensuring  stability  of  operation  [Ref  12:  p.l  12].  The  swallowing 
capacity  of  the  engine  downstream  of  the  compressor  is  important  in  preventing  surge 
from  occurring,  and  will  be  utilized  and  discussed  in  the  control  process.  With  this  in 
mind,  the  key  factor  used  in  the  baseline  expert  system  for  diagnosing  compressor  surge 
potential  onset  was  a  significant  disagreement  between  the  ideal  behavior  expressed  by 
the  model,  and  the  actual  measured  engine  behavior.  If  disagreement  existed  it  was 
further  analyzed  to  determine  if  the  actual  operating  point  was  located  closer  to  the 
surge  line  then  called  for  by  the  model  (indicating  surge  potential)  or  further  from  the 
surge  line  (indicating  a  non-surge  potential  condition). 

Since  the  desired  outputs  of  the  real  time  simulator  have  been  identified,  the  task 
has  become  one  of  modifying  the  model  to  provide  compressor  speed,  mass  air  flow  and 
outlet  pressures  from  the  states.  This  operation  was  previously  discussed  at  the  end  of 
Chapter  Five  (equations  (5.12)  and  (5.13)). 

The  actual  plant,  however,  does  not  allow  as  much  flexibility  as  the  model  in  that 
all  of  the  required  surge  indicator  outputs  are  not  directly  accessible  through  sensor 
measurements.  Although  compressor  speed  and  inlet  and  outlet  pressures  can  be 
measured,  the  air  flow  rate  through  the  compressor  must  be  arrived  at  indirectly. 
Therefore,  it  was  assumed  that  the  aerothermal  indicators  which  the  actual  plant  sends 
to  the  processor  would  be  compressor  speed,  compressor  discharge  pressure,  compressor 
inlet  pressure,  and  nozzle  pressure.  Output  from  the  simulator  included  compressor 
model  speed,  compressor  model  air  mass  flow  rate,  and  compressor  model  discharge 
pressure. 
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The  first  step  in  the  data  preparation  process  was  to  establish  identical  indicators 
from  model  and  plant.  Namely,  actual  (plant)  compressor  speed  would  be  compared  to 
model  speed,  actual  compressor  pressure  ratio  would  be  compared  with  model  (simula¬ 
tor)  pressure  ratio,  and  actual  air  mass  flow  rate  compared  to  model  flow  rate.  To  ac¬ 
complish  this,  compressor  pressure  ratio  for  both  model  and  the  plant,  as  well  as  plant 
air  mass  flow  rate  through  the  compressor,  needed  to  be  computed.  Since  model 
compressor  outlet  pressure  was  computed  by  the  simulator,  model  pressure  ratio  was 
easily  determined  by  dividing  the  model  outlet  pressure  with  the  actual  measured 
compressor  inlet  pressure.  Similarly,  plant  pressure  ratio  was  computed  by  dividing 
measured  compressor  outlet  pressure  by  measured  inlet  pressure.  Since  plant  inlet  and 
nozzle  pressures  were  measured  directly,  plant  air  mass  flow  rate  could  be  calculated 
utilizing  a  simplified  version  of  the  mass  flow  rate  equation  for  compressible  flow 
through  a  nozzle  [Ref  17;  p.237].  (Note  that  equation  simplification  was  allowed  since 
the  differential  pressure  over  inlet  pressure  ratio  was  less  than  0.10): 


m,=  YKA^2g,p{P,-P^) 


(6.1) 


Applying  the  standard  temperature  and  pressure  correction  factors  to  equation  (6.1) 
yields: 


(6.2) 


Also,  since: 


(6.3) 


equation  (6.2)  can  be  rearranged  to  yield: 
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(6,4) 


Final  simplification  of  equation  (6.4)  yields; 


A 


(6.5) 


where  C  is  a  constant  equalling  15.0706  for  the  Boeing  gas  turbine's  compressor. 

Having  established  the  selected  compressor  surge  indicators  (or  those  variables 
needed  to  calculate  them)  for  both  plant  and  model,  the  next  procedure  required  was  to 
have  both  sets  of  inputs  read  and  entered  into  the  expert  systems's  fact  list. 

The  real  time  simulator  inputs  were  directly  entered  into  the  expert  system's  fact  list 
through  file  manipulation  once  the  model  values  for  compressor  speed,  flow  rate  and 
compressor  outlet  pressure  were  computed.  The  measured  plant  inputs,  for  baseline 
development  purposes,  were  input  manually  into  a  text  file,  and  read  by  the  main  pro¬ 
gram  after  the  above  mentioned  model  surge  indicator  values  had  been  computed.  The 
repetitive-cycle  sequence  of  events  then  went  as  follows: 

1.  main  simulator  code  computes  model  compressor  speed,  air  mass  How  rate  and 
oulet  pressure  from  existing  plant  initial  conditions  and  plant  inputs  (load  and  fuel 


How  rate), 


2.  main  simulator  code  reads  measured  plant  surge  inputs  of  compressor  speed.inlet, 
outlet  and  nozzle  pressures  from  text  file  (plant.txt), 

3.  all  seven  indicators  (model's  and  plant's)  are  sent  to  a  data  file  (turb.dat), 

4.  the  embedded  CLIPS  subroutine  (surge.clp)  then  reads  the  data  file  and  enters  the 
input  into  its  fact  list, 

5.  the  two  sets  of  indicators  are  manipulated,  compared 'analyzed  and 

6.  finally,  diagnosis  displayed  and  control  action  taken. 

In  the  present  system  a  timed,  analog-to-digital  board  was  assumed  to  be  used  in  con¬ 
junction  with  the  input  output  capabilities  of  CLIPS  for  the  purpose  of  entering  the 
actual  plant  data  directly  into  the  CLIPS  subroutine's  fact  list.  The  main  simulator  code 
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(rltms.c)  can  be  referred  to  in  Appendix  C.  The  main  simulator  code  (rltms.c)  is  similar 
to  the  C  version  of  the  real  time  simulator  program  (rts.c)  contained  in  Appendix  B, 
except  for  the  required  CLIPS  interface  commands  and  the  additional  commands  to 
handle  the  reading  and  transfer  of  the  measured  plant  data. 

Notice  that  the  above  control  procedure  relies  on  an  ability  of  the  expert  system  to 
detect  significant  deviations  between  the  model  and  actual  data.  Consequently,  this 
implementation  forces  the  programmer  to  decide  on  allowable  operating  windows  or 
tolerances  for  the  three  health  indicator  values  used.  At  this  point  it  becomes  necessary 
to  develop  an  understanding  of  the  differences  in  purpose  and  development  between  an 
engine  health  monitoring  system  and  an  expert  system  for  casualty  control. 

In  developing  an  engine  health  monitoring  system,  one  of  the  first  requirements  is 
to  develop  what  are  known  as  an  operating  baselines.  Operating  baselines  are  a  product 
of  countless  data  recording,  taken  under  various  operating  conditions.  The  data  is  then 
plotted  to  recognize  the  degree  of  scatter  for  the  various  parameters,  and  the  collective 
curves  are  fitted  to  form  the  baselines.  With  the  operating  baselines  used  as  references, 
the  engine  health  monitoring  system  develops  trend  plots.  What  is  important,  however, 
and  distinquishes  a  health  monitoring  system  from  a  casualty  control  system,  is  that  it 
is  not  essential  that  trend  plots  are  developed  with  zero  deviation  from  the  baseline  for 
each  parameter,  but  rather  the  percentage  deviation  change  from  the  baseline  with  time 
[Ref  18;  p.3].  The  reason  percentage  deviation  with  time,  and  not  zero  deviation  from 
the  baseline  is  important  is  that  the  main  function  of  an  engine  health  monitoring  system 
is  trend  assessment.  In  an  expert  system  for  casualty  control,  the  real  time  simulator 
takes  the  place  of  the  operating  baselines.  While  operating  baselines  provide  a  general 
reference  for  various  parameters,  their  use  is  restricted  to  steady  state  (stable)  conditions 
[Ref  18:  p.5].  A  real  time  simulator,  however,  provides  a  specific  set  of  data  which 
decribes  the  exact,  dynamic  state  of  the  engine  at  a  particular  instant  in  time.  It  can  be 
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used  under  steady  state  or  dynamic  conditions.  Unlike  the  health  monitoring  system, 
response  time  is  critical  with  a  casualty  control  system,  so  deviations  from  an  operating 
parameters  provided  by  the  real  time  simulator  need  to  be  carefully  and  quickly  scruti¬ 
nized  to  determine  if  immediate  control  action  is  required.  The  problem  then  becomes 
one  of  determining  acceptable  deviations  from  simulated  operating  points  before  control 
action  is  mandated. 

To  accurately  define  acceptable  tolerances,  a  number  of  factors  have  to  be  consid¬ 
ered.  Some  of  these  factors  include:  accuracy  of  the  real  time  simulator  (model),  accu¬ 
racy  of  aerothermal  and  mechanical  sensors,  and  effectiveness  of  data  filters.  In 
developing  the  present  expert  casualty  control  system  for  surge  control,  a  large  amount 
of  eflbrt  was  not  spent  on  accurately  determining  allowable  deviation..  This  was  largely 
due  to  the  fact  that  certain  required  equipment  (such  as  sensor  data  filters)  were  not  in¬ 
stalled.  and  that  the  modeling  methods  used  seemed  to  agree  with  uncertainty  calcu¬ 
lations  on  engine  parameters  calculated  during  numerous  gas  turbine  laboratory 
e.xperiments  conducted  at  the  facility.  In  determining  the  individual  allowable  devi¬ 
ations.  each  parameter's  operating  range  was  computed,  and  then  multiplied  by  0.03. 
A  three  percent  value  was  used  because  greater  differences  is  operating  conditions  would 
be  considered  e.xtreme  for  gas  turbine  engines.  Compressor  speed  tolerance  determined 
was  (plus  or  minus)  350  rpm,  pressure  ratio  tolerance  was  0.035,  and  air  mass  flow  rate's 
window  was  found  to  be  0.06  Ibm'sec. 

Having  established  the  tolerances  for  the  simulated  (model)  surge  indicators,  the 
next  step  was  to  apply  these  deviations  to  the  model's  indicators  to  acheive  allowable 
tolerance  windows.  In  other  words,  deviations  were  both  added  and  subtracted  to  the 
model's  pressure  ratio,  speed,  and  flow  rate  to  produce  a  high  model  rpm  value,  a  low 
model  rpm  value,  a  high  model  pressure  ratio  value,  a  low  model  pressure  ratio  value,  a 
high  model  flow  rate  value,  and  a  low  model  flow  rate  value. 


31 


Having  applied  the  tolerance  windows,  thereby  establishing  allowable  parameter 
limits,  the  next  step  was  to  compare  the  actual  plant  indicators  to  their  model  counter¬ 
part  indicators  to  determine  if  the  measured  values  fell  within  the  established  operating 
windows.  In  accomplishing  this  the  comparison  process  was  broken  down  into  three 
broad  cases;  plant  compressor  speed  being  within  model  speed  limits,  plant  compressor 
speed  being  greater  than  model  limits  and  compressor  speed  being  less  than  model 
(simulator)  limits.  In  all  cases  the  same  surge  onset  indicator  was  looked  for,  that  being, 
if  plant-model  indicator  deviation  was  determined,  did  the  plant's  compressor  charac¬ 
teristics  (speed,  pressure  ratio,  and  air  mass  flow  rate)  position  the  compressor  operating 
point  closer  or  further  from  the  surge  line  than  did  the  model's  characteristic  indicators. 

Before  describing  in  detail  the  logic  surrounding  these  three  broad  cases  some 
background  on  the  Boeing  502-2E  compressor  map,  its  associated  surge  line  and  the 
applied  surge  control  line  needs  to  be  introduced.  For  the  present  study,  efforts  were 
made  to  locate  an  original  compressor  map  for  the  Boeing  model  502-E  gas  turbine  en¬ 
gine's  compressor  without  success.  Owing  to  the  fact  that  the  engine  is  over  thirty  years 
old,  the  historical  archives  department  at  Boeing  was  contacted,  but  an  original 
compressor  map  could  not  be  found.  To  circumvent  this  problem,  actual  pressure  ratio 
and  air  mass  flow  rate  data  was  plotted  at  various  steady  state  compressor  speeds  under 
various  loadings  (see  Figure  11). 
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Figure  II.  Steady  State  Compressor  Data 
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By  combining  Figure  1 1  with  some  fabricated  data  points  (based  on  general  compressor 
mapping  criteria)  a  compressor  map  for  the  Boeing  engine  was  contructed.  Figure  12 
shows  this  construction. 
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Figure  12  shows  a  hypothetical  surge  line  on  the  NFS  gas  turbine  compressor.  The 
surge  line  being  the  line  that  connects  the  surge  points  at  various  compressor  speeds. 
Generally,  the  surge  point  is  located  at  the  compressor  characteristic  curve's  peak  (as 
implied  in  Chapter  Three)  where  the  slope  changes.  Here,  however,  allowances  have 
been  made  for  the  centrifugal  compressor  stability.  Figure  13  shows  the  compressor 
map  with  the  surge  control  line  added.  The  surge  control  line  in  the  baseline  expert 
surge  control  system  was  a  fixed  straight  line  which  ran  as  parallel  as  possible  to  the 
compressor  surge  line.  The  distance  between  the  surge  control  line  and  the  surge  line 
determined  the  amount  of  surge  protection  offered  by  the  system. 
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Figure  13.  Compressor  Map  with  Surge  Control  Line 


COMPRESSOR  MAP 


Having  defined  all  the  applicable  surge  related  terms  and  having  been  introduced  to 
the  NFS  Boeing  compressor  map  used  in  this  study,  the  three  previously  mentioned  in¬ 
dicator  comparison  cases  can  now  be  examined.  The  following  How  chart  of  the  em¬ 
bedded  CLIPS  subroutine  (surge.clp)  visually  explains  the  logic  and  reasoning  used  for 
the  three  cases  analyzed,  and  will  be  of  assistance  in  understanding  the  embedded  expert 
system  program.  The  first  two  pages  of  the  flow  chart  apply  to  the  equal  speed  situ¬ 
ation,  the  next  two  pages  apply  to  the  case  of  compressor  speed  being  greater  than 
model  limits  and  the  last  flow  chart  is  concerned  with  compressor  speed  being  lower  than 
model  limits. 
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Note  1 .  *  respresent  simulator  or  model  terms 

Note  2.  Data  file  “Turb.dal”  contains  the  following  data  in  the  order  listed. 
Note  3.  K,  represents  the  slope  of  the  surge  control  line 

Turb.dal 

No 

P. 

P, 

Pn 

No* 

m/ 

Pj* 


Figure  14.  Flow  Chart  pg.l 
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Figure  15.  Flow  Chart  pg.2 
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Figure  16.  Flon  Chart  pg.3 
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Figure  17.  Flow  Chart  pg.4 
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Figure  18.  Flow  Chart  pg.5 
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The  case  of  plant  speed  being  within  model  speed  limits  will  be  examined  first.  This 
general  case  can  be  further  broken  down  into  three  subcategories;  plant  speed  and 
pressure  ratio  within  model  limits  ("equal"),  plant  speed  equal  to  model  speed  with  high 
measured  air  mass  flow  rate,  and  plant  speed  equal  to  model  speed  with  low  air  mass 
flow  rate.  Taking  the  flrst  subcategor\',  if  compressor  speed  and  pressure  ratio  are  de¬ 
termined  to  be  within  model  limits,  then  the  flow  rate  must  also  be  within  limits,  there¬ 
fore,  a  display  will  result  stating  "plant  within  specifications."  If  pressure  ratios  are 
different  at  the  same  speed,  then  air  mass  flow  rates  will  have  to  be  different,  and  either 
actual  flow  rate  is  higher  or  lower  than  model  limits.  So,  if  plant  air  mass  flow  rate  is 
lower  than  the  model's  low  flow  rate  limit,  compressor  choking  could  occur  if  flow  rate 
continued  to  drop.  Accordingly,  if  these  characteristics  exhibitted  themselves  a  message 
stating,  "choke  potential  if  trend  continues"  would  be  displayed.  On  the  other  hand  if 
the  expert  system  code  determined  that  speeds  were  equal  but  compressor  mass  air  flow 
rate  was  lower  than  model  limits,  the  plant  would  be  operating  closer  to  the  surge  line 
than  the  model,  and  the  message  "surge  control  need  possible"  would  be  displayed.  The 
plant  characteristics  would  then  be  utilized  in  the  previosly  discussed  surge  test  to  de¬ 
termine  if  the  compressor  is  operating  beyond  the  surge  control  line.  If  it  is,  "surge 
control  activated"  will  be  displayed. 

The  general  case  of  actual  compressor  speed  falling  outside  model  speed  limits  is  a 
more  complicated  scenario;  however,  similar  reasoning  was  used  to  determine  appropri¬ 
ate  outputs,  only  now,  instead  of  examining  two  variable  combinations,  three  variables 
must  be  analyzed.  Again,  compressor  speed  is  used  to  distinguish  between  cases.  This 
time  subcategories  are  broken  into  actual  compressor  speed  being  lower  than  model 
speed  limits,  and  measured  speed  being  higher  than  model  speed  limits.  With  actual 
compressor  speed  being  higher  than  model  speed  limits  the  next  variable  examined  is 
flow  rate.  If  the  compressor's  measured  flow  rate  is  within  limits,  this  would  imply  that 
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the  actual  pressure  ratio  would  be  higher  than  the  model's  (while  operating  in  the  neg¬ 
ative  slope  region  of  the  compressor  map),  and  that  the  operating  point  would  be  closer 
to  the  surge  control  line.  This  would  generate  the  message  "surge  control  need  possible," 
and  the  measured  plant  parameters  would  be  used  to  check  if  the  surge  control  line  was 
crossed.  If  the  air  mass  flow  rate  was  not  equal,  while  the  plant  compressor  speed  was 
higher  than  the  model's,  the  flow  rate  cases  of  higher  and  lower-than  model  flow’  rate 
w'ould  have  to  be  examined  seperately.  Higher  measured  compressor  speed  and  low’er 
measured  air  mass  flow  rate  would  again  have  an  operating  point  closer  to  the  surge 
control  line  then  the  model's  operating  point,  and  the  w’arning  "surge  need  possible" 
would  flash  on  the  screen.  Additionally,  with  the  warning  comes  the  checking  of  the 
actual  operating  point  to  see  if  the  compressor  is  in  surge  danger  by  determining  if  the 
control  line  has  been  crossed.  How’ever,  if  the  measured  air  mass  flow’  rate  w’as  greater 
than  the  model's,  while  the  actual  compressor  speed  remains  greater,  the  outcome  is  not 
as  straight-forward  as  previous  cases.  In  this  case,  the  subcategory  w'ould  be  further 
broken  down  into  measured  pressure  ratio  being  greater  than  model  limits,  and  actual 
pressure  ratio  being  less  than  or  equal  to  model  pressure  ratio  limits.  The  proper  diag¬ 
nosis  will  be  determined  by  the  magnitudes  of  the  differences  betw’een  measured  and 
actual  pressure  ratios  and  air  mass  flow  rates.  If,  for  the  case  of  high  measured  pressure 
ratio,  the  pressure  ratio  difference  (measured  minus  model)  divided  by  the  flow  rate  dif¬ 
ference  is  greater  than  the  slope  of  the  surge  control  line,  then  the  actual  compressor 
operating  point  is  closer  to  the  control  line.  Being  closer  to  the  surge  line,  the  expert 
system  w’ould  initiate  the  standard  "surge  control  need  possible"  w’arning,  and  the  actual 
operating  point  would  be  checked  to  determine  if  surge  control  w^as  indeed  required. 
How’ever,  if  while  the  measured  speed  and  flow  rate  were  greater,  the  actual  pressure 
ratio  was  less  than  or  equal  to  the  model's  pressure  ratio  the  compressor  w’ould  not  be 
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in  surge  danger,  but  could  possibly  be  in  a  compressor  choking  situation,  and  an  ap¬ 
propriate  message  would  be  displayed. 

Lastly,  the  general  case  of  measured  compressor  speed  being  less  than  model  speed 
needed  to  be  investigated.  As  with  the  case  of  measured  compressor  speed  being  greater 
than  model  limits,  three  variables  need  to  be  scrutinized.  The  same  general  principles 
and  reasoning  that  were  used  in  the  later  case  (measured  speed  greater)  were  again  ap¬ 
plied  to  arrive  at  proper  compressor  diagnosis  and  determine  if  compressor  control 
action  was  required. 

The  "surge  test",  which  was  referred  to  in  the  above  case  descriptions,  is  simply  a 
check  to  see  if  the  plant's  operating  point  has  crossed  the  surge  control  line.  The  con¬ 
cept  behind  the  surge  test  is  straightforward,  and  in  some  respects  resembles  the  over¬ 
view  of  the  simplified  universal  anti-surge  control  system  given  in  [Ref  19:  pp. 84-85]. 
The  mechanics  of  the  surge  test  descibed  below  utilizes  the  equation  of  the  surge  control 
line  along  with  the  measured  plant  parameters.  Writing  the  surge  control  line  in  stardard 
line  equation  form  (Y  =  m  X  +  b)  yields: 


(6.6) 


Subtracting  one  from  both  sides  and  multiplying  through  by  compressor  inlet  pressure 
equation  (6.6)  becomes: 


Pj  -  Pj  =  0.7534m^Pi  -  0.7602Pi 


(6.7) 


Substituting  equation  (6.5)  for  mass  flow  rate,  and  organizing  terms  yields: 


(6.8) 
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If,  after  measured  plant  values  for  the  inlet,  outlet,  and  nozzle  pressures  have  been  sub¬ 
stituted  into  equation  (6.8)  the  left  hand  side  of  the  equation  is  determined  to  be  greater 
than  the  left  hand  side  than  the  compressor's  operating  point  has  indeed  crossed  the 
surge  control  line,  and  surge  control  action  is  required.  As  is  the  case  with  the  universal 
anti-surge  control  system  decribed  in  [Ref  19:  p.83],  the  baseline  expert  surge  control 
system  ultimately  provides  surge  protection  by  not  allowing  the  compressor  to  operate 
to  the  right  of  the  surge  control  line,  thus  establishing  a  surge  margin  of  safety.  It  has 
been  assumed,  due  to  the  relative  close  proximity  of  the  control  line  to  the  surge  line, 
that  the  real  time  simulator  operating  points  would  not  cross  the  surge  control  line,  and 
yet  come  close  enough  to  it,  in  order  to  ensure  maximum  compressor  operating  effi¬ 
ciency.  Under  current  system  configuration,  however,  if  the  simulator  happened  to  track 
through  the  surge  control  line,  the  surge  control  system  would  not  be  activated  as  long 
as  the  plant  surge  indicators  remain  within  model  limits. 

The  most  common  type  of  surge  protection  used  on  compressors  (not  the  LM-2500), 
is  through  the  use  of  blow-off  or  recirculation  valves  [Ref  20:  p.40].  These  systems 
protect  against  surge  by  measuring  existing  compressor  conditions  and  checking  that 
pre-established  limits  are  not  exceeded.  If  these  limits  are  compromised  the  blow-off  (or 
recirculation)  valve  is  automatically  openned,  and  operating  limits  are  restored  to 
exceptable  levels.  Two  typical  types  of  blow-off  surge  protection  systems  from  [Ref 
21:  p.  184]  are  shown  in  Figure  19  and  Figure  20. 
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Figure  19.  Pressure  Oriented  Anti-Surge  Control  System 
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The  principle  behind  the  blow- off  (and  recirculation)  valve  is  simply  that  by  opening  the 
valve,  which  is  located  just  downstream  of  the  compressor,  positive  air  flow  is  main¬ 
tained  through  the  compressor  because  the  negative  pressure  gradient  is  controlled. 

An  anti-surge  control  device  which  could  be  easily  incorporated  into  the  baseline 
expert  control  system  is  a  version  of  the  blow-off  valve  principle.  The  difference  between 
the  ordinary  blow-oIT  valve  surge  controller  and  the  baseline  expert  sytem  is  that  the 
latter  system,  through  the  use  of  the  real  time  simulator,  is  able  to  provide  a  continuous 
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display  of  plant-model  deviation.  Additionally,  it  may  utilize  simulator  data  as  feedback 
information  to  the  plant  controller  and  blow-off  valve  to  vector  the  compressor's  meas¬ 
ured  operating  point  to  within  agreement  of  the  model's  location  on  the  compressor 
map.  And  lastly,  the  expert  surge  controller,  by  the  nature  of  expert  systems,  could  be 
easily  expanded  to  provide  additional  engine  casualty  protection. 

In  summary,  the  expert  system  performs  the  following  tasks  in  the  sequence  listed: 
Plant  inputs  are  received  by  the  plant  and  real  time  simulator,  the  plant  responds  and 
the  real  time  simulator  predicts  the  nominal  compressor  operating  point,  the  measured 
surge  indicator  data  is  read  by  the  embedded  expert  analysis  routine  where  it  is  massaged 
and  compared  with  surge  indicator  limits,  and  finally,  the  comparison  analysis 
compressor  status  is  displayed.  If  the  actual  operating  point  was  determined  to  be  closer 
to  the  surge  control  line  than  the  model  called  for,  a  surge  test  is  conducted  to  determine 
if  the  control  line  has  been  crossed.  If  the  surge  control  line  has  indeed  been  compro¬ 
mised,  the  system  would  provide  simulator  feedback  to  the  plant  controller  and  the 
blow-off  valve,  which  would  work  in  conjuction  with  each  other  to  reestablish  agreement 
between  plant  and  model. 
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VII.  RESULTS 


Discussion  of  results  will  be  broken  down  into  three  areas:  real  time  simulator 
testing  and  results,  CLIPS  subroutine  testing  and  results,  and  integrated  system  testing 
and  results. 

As  discussed  in  Chapter  Five,  the  testing  of  the  real  time  simulator  was  accom¬ 
plished  for  accuracy  and  timing  under  basically  four  different  conditions.  Initially  the 
code  was  tested  for  accuracy  under  constant  gas  generator  (or  compressor)  speeds  and 
agreement  between  predicted  model  values  and  measured  steady  state  values  were  quite 
good.  Then  using  the  same  simulator  structure  the  programming  code  was  changed 
from  DSL  to  Fortran  77,  and  a  timing  study  was  conducted  on  a  32  bit  processor. 
Timing  test  results  revealed  that  0.13  seconds  of  computing  time  was  required  for  each 
second  of  simulated  time.  Because  a  CLIPS  to  Fortran  interface  package  would  have 
been  required  to  make  the  Fortran  version  of  the  simulator  interactive  with  the  CLIPS 
language  subroutine,  the  obvious  alternative  was  to  change  the  Fortran  version  of  the 
simulator  to  C,  as  the  interface  functions  between  C  and  CLIPS  exist  in  the  CLIPS  code. 

Testing  of  the  real  time  simulator  in  C,  under  transient  gas  generator  conditions, 
with  load  and  fuel  flow  equations  included  in  the  code  to  estimate  system  inputs  yielded 
close  agreement  with  actual  measured  data  after  the  program's  time  step  was  modified 
from  0.001  to  0.000368.  Figure  21  illustrates  how  the  simulator  output  tracked  right 
along  measured  data  taken  at  the  various  compressor  speeds  shown.  On  a  16  bit 
processor,  using  an  optimizing,  turbo  C  compiler,  a  simulated  ten  second  run  took  47 
seconds  of  computation  time.  Or,  for  each  second  of  simulated  time  4.7  seconds  of 
computation  time  was  required. 
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Figure  21.  Simulator  Test  Results 


COMPRESSOR  MAP 


The  next  portion  of  the  baseline  system  which  had  to  be  tested  was  the  CLIPS 
subroutine  code  (surge.clp)  which  would  be  embedded  into  the  main  C  simulator  code. 
This  testing  was  done  in  the  CLIPS  executable  mode,  in  order  that  each  rule  of  the 
subroutine  could  be  tested  seperately  to  ensure  actual  output  agreed  with  anticipated 
output.  In  order  to  accomplish  this  twelve  different  data  sets  were  constructed,  and  in¬ 
dividually  read  into  the  programs  fact  list  during  code  rule  testing.  Since  it  was  known 
ahead  of  time  how  many  rules  should  be  triggered  or  fired,  and  also  what  the  output 
should  be,  based  on  the  particular  data  set  entered,  it  was  relatively  simple  to  determine 
if  the  program  was  functioning  as  anticipated.  The  twelve  sets  of  data  combinations  of 
compressor  speed,  pressure  ratio,  and  air  flow  rate  are  listed  in  Table  1. 


Table  1.  CLIPS  SUBROUTINE  TESTING 


Nominal 

rpm  = 

pr  = 

Choke  Potential  1. 

rpm  = 

pr  < 

Choke  Potential  2. 

rpm  > 

pr  < 

air  > 

Choke  Potential  3. 

rpm  < 

air  > 

Out.  No  Danger  1. 

rpm  < 

pr  < 

air  > 

Out.  No  Danger  2. 

SLOPE 

TEST  1 

LOW 

Out.  No  Danger  3. 

SLOPE 

TEST  2 

HIGH 

Out.  No  Danger  4. 

SURGE 

TEST 

FAILED 

Slope  Test  1. 

rpm  > 

pr  >  or  = 

air  > 

Slope  Test  2. 

rpm  < 

air  < 

Surge  Test  1. 

rpm  = 

pr  > 

Surge  Test  2. 

rpm  > 

air  = 

Surge  Test  3. 

rpm  > 

air  < 

Surge  Test  4. 

SLOPE 

TEST  1 

HIGH 

Surge  Test  5. 

SLOPE 

TEST  2 

LOW 

Surge  Control  Req'd 

SURGE 

TEST 

PASSED. 

It  should  be  noted,  however,  that  input  data  was  read  by  the  subroutine  as  compressor 
speed,  and  inlet,  outlet,  and  nozzle  pressures.  For  illustration  purposes,  the  computation 
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which  occured  in  the  initial  part  of  the  subroutine,  (flow  rate  and  pressure  ratio)  were 
performed  before  this  test  was  conducted.  Individual  response  tests  conducted  were 
successful  in  that  all  anticipated  responses  agreed  with  those  anticipated  from  the  data 
sets  input. 

The  last  testing  conducted  was  the  integrated  testing  phase,  during  which  all  com¬ 
ponents  of  the  baseline  expert  diagnosis  system  were  tested  together,  during  a  dynamic 
response  simulation.  The  framework  for  the  dynamic  integrated  expert  system  testing 
is  shown  in  Figure  22. 


Diagnosis  and  Control  Action 


Figure  22.  Dynamic  Response  Testing  Framework 
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In  achieving  this  goal,  an  engine  histor\'  test  file  was  fabricated  containing  twenty  sets 
of  data  that  would  be  independently  read  by  the  system  during  normal  operation  at  half 
second  intervals.  (Recall  that  the  system  receives  four  measured  data  values  for  each  run 
loop.)  The  fabricated  data  was  constructed  in  such  a  way  that  different  system  diagnoses 
could  be  dynamically  tested,  while  keeping  the  inputs  realistic.  The  integrated  testing 
run  was  to  simulate  a  change  in  gas  generator  speed,  created  by  a  changing  load,  over 
a  time  span  of  ten  seconds,  with  outputs  provided  by  the  simulator  every  half  second. 
The  data  sampling  rate  of  a  half  second  was  determined  by  actual  system  load  and  fuel 
flowrate  input  measurements  taken  from  a  strip  chart  recording,  which  were  then  molded 
into  input  equations  and  utilized  in  the  simulator  code,  as  previously  discussed  in 
Chapter  Five.  A  graphical  representation  of  the  dynamic,  integrated  testing  results  is 
contained  in  Figure  23,  with  the  output  display  response  corresponding  to  each  of  the 
twenty  measured  operating  points  given  below. 
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Figure  23.  Integrated  System  Test  Plot 


COMPRESSOR  MAP 
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Response  one  below  corresponds  to  the  measured  operating  point  at  the  bottom  left  of 
Figure  23,  and  similarly  response  number  twenty  at  the  top  right  of  the  plot. 

1.  plant  within  specification 

2.  plant  within  specification 

3.  plant  within  specification 

4.  plant  within  specification 

5.  plant  within  specification 

6.  plant  within  specification 

7.  surge  control  need  possible. ..out  of  specs;  not  enough  to  activate  surge  control 
system 

8.  surge  control  need  possible.. .out  of  specs;  not  enough  to  activate  surge  control 
system 

9.  surge  control  need  possible.. .surge  control  activated 

10.  plant  within  specification 

11.  plant  within  specification 

12.  choke  potential  if  trend  continues 

13.  plant  within  specification 

14.  surge  control  need  possible.. .out  of  specs;  not  enough  to  activate  surge  control 
system 

15.  plant  out  of  specs,  no  surge  danger 

16.  surge  control  need  possible... out  of  specs;  not  enough  to  activate  surge  control 
system 

17.  plant  in  no  danger  of  surging 

1 8.  plant  within  specification 

19.  plant  in  no  danger  of  surging 

20.  plant  within  specification 

As  can  be  seen  from  Figure  23,  the  baseline  expert  system  output  agrees  with  what 
one  would  anticipate  by  comparing  the  plant  and  model  operating  points.  Additionally, 
during  the  integrated  system  testing  phase  a  timing  study  w^as  conducted  to  determine 
the  time  required  to  cycle  through  one  half  second  sampling 'computing  loop.  This  loop 
contained  simulator  data  computation,  model  and  measured  surge  indicator  reading,  in¬ 
dicator  comparison  and  analysis,  and  finally  diagnosis  output.  It  was  found  that  to  run 
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an  executable  (,exe)  file  consisting  of  twenty  interations  or  loops,  on  a  16  bit  processor 
using  an  optimizing  Turbo  C  compiler,  it  took  approximately  110  seconds;  or  5.5  sec¬ 
onds  per  half  second  system  loop. 
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VIII.  CONCLUSIONS  AND  RECOMMENDATIONS 


Before  examining  and  discussing  specific  sytem  testing  results,  some  general  obser¬ 
vations  can  be  made  regarding  the  baseline  expert  surge  control  system  development: 

1.  A  veiy  limited  amount  of  literature  exists  in  the  marine  gas  turbine  expert  system 
arena, 

2.  No  literature  or  research  work  could  be  found  in  the  more  specific  combined  topic 
of  compressor  surge  and  expert  systems, 

3.  The  majority  of  expert  system  gas  turbine  research  is  being  conducted  in  the  steady 
state,  industrial  gas  turbine  environment, 

4.  The  limited  amount  of  reseach  taking  place  in  the  area  of  expert  systems  and  ma¬ 
rine  gas  turbines  is  primarily  directed  towards  engine  monitoring  vice  engine  con¬ 
trol  or  engine  diagnosis  and  control,  and 

5.  The  phenomenon  of  compressor  surge  is  still  not  completely  understood,  even  by 
experts  in  the  turbomachinery  field. 


Focussing  attention  closer  to  the  actual  baseline  system  development  itself,  the  fol¬ 
lowing  observations  were  made  while  constructing  the  individual  system  components: 

1.  The  sequential  linearization  technique  used  in  the  development  of  the  system's  real 
time  simulator  is  an  effective  means  of  determining  the  gas  turbines  state,  from 
which  other  parameters  can  be  calculated, 

2.  The  executable  version  of  CLIPS  was  an  efficient  and  effective  tool,  which  greatly 
simplified  expert  system  code  development, 

3.  CLIPS  integration  capabilities  are  noteworthy,  thus  eliminating  embedded  appli¬ 
cation  difficulties,  and 

4.  CLIPS  was  veiy-  portable  and  worked  flawlessly  with  a  Boreland  turbo  C  compiler. 


Specific  conclusions  focussing  on  individual  component  and  integrated  system  test¬ 
ing  results  revolve  around  two  issues,  accuracy  and  timing.  Overall,  the  integrated  sys¬ 
tem  achieved  the  desired  output,  however,  two  areas  of  concern  arise.  The  first  being 
that,  in  order  to  be  an  effective  system  to  prevent  compressor  surging,  the  system's  loop 
(or  one  complete  cycle)  execution  time  has  to  be  in  the  order  of  less  than  one  half  a 
second.  Currently  it  is  taking  the  system  5.5  seconds  of  execution  time  for  eveiy  half 
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second  of  simulated  time.  Clearly,  under  current  configuration  this  is  an  unworkable, 
non-  real  time  system.  Considerable  decreases  in  execution  time  possibly  may  be 
achieved  by  moving  the  baseline  system  to  a  32  bit  processor  vice  the  slower  16  bit. 
Lastly,  in  regards  to  system  accuracy,  but  also  related  to  timing  concern,  is  the  scaling 
factor  problem  that  was  encompassed  when  the  simulator  code  w'as  tested  under  varxing 
gas  generator  speeds.  Although  simulator  data  agreed  wath  measured  data  after  the 
simulator  code's  iteration  step  size  was  changed,  further  simulator  code  testing  needs  to 
be  accomplished  under  various  gas  generator  operating  conditions. 

With  these  concerns  in  mind  the  following  recommendations  concerning  continued 
interest  in  the  development  of  an  expert  casualty  control  system  for  marine  gas  turbines 
are  proposed; 

1.  Conduct  baseline  expert  surge  control  system  testing  on  a  32  bit  processor, 

2.  Conduct  further  simulator  code  testing  under  various  operating  conditions,  specif¬ 
ically  var}'ing  gas  generator  speed. 

3.  Develop  specifics  on  the  surge  control  strategy,  enabling  simulator  data  to  be  used 
in  the  control  process  by  the  plant  controller  and  surge  protection  blow-off  valve. 

4.  Install  the  baseline  expert  surge  control  system  on  the  NFS  Boeing  gas  turbine  for 
online  system  testing. 

5.  Futher  investigate  specifics  for  possible  incorporation  of  an  expert  surge  control 
system  on  the  LM-2500  engine,  and 

6.  Expand  the  baseline  e.xpert  system's  know'ledge  base  to  facilitate  additional  gas 
turbine  engine  casualties. 

Lastly,  in  a  recent  artical  published  by  the  American  Society  of  Naval  Engineers,  the 
author  beckoned  engineers,  naval  architects,and  managers  to  [Ref  22:  p.39]: 

1.  "Examine  the  field  of  expert  systems, 

2.  Get  people  involved, 

3.  Pick  the  most  promising  problems,  document  them,  and  distill  the  expert  know¬ 
ledge  required  to  solve  them 

4.  Make  this  technology  availiable, 

5.  Build,  test,  and  use  the  systems  to  save  time  and  money,  now'  and  in  the  future." 

If  for  nothing  else,  this  thesis  has  answered  his  call. 
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APPENDIX  A.  FORTRAN  REAL  TIME  SIMULATOR  CODE 


REAL  NG,NS,NGN,MF,MFI 
C  establish  the  initial  conditions 
NG  =  349000.0 
NS  =  570.  0 
E  =  193.5 
MFI  =  193.5 
QLI  =  405.  0 

C  establish  the  initial  offset  values-note  that  these  are  not  the 
C  not  the  perturbations,  at  any  time  step  they  are  equal  to  the 
C  previous  offset  from  the  initial  condition  plus  the  pertibations 
DNG=0.  0 
DNS=0.  0 
DE=0. 0 

C  set  the  normalizing  values 
NGN=26000 
NSN=1750 
c 

c  the  100  do  loop  is  the  simulation  loop 
DO  100  n=l, 100000 
C 

All=-1.  0*EXP( -0.  6993*(NS/NSN)+5. 583*(NG/NGN) -3. 2433) 
c 

A12=-l. 0*EXPC-2. 8415*(NS/NSN)+7.  9978*(NG/NGN) -4.  4662) 
c 

A13=EXP(-0.  4579*(NS/NSN)+1. 189*(NG/NGN)+6. 8305) 
c 

A21=0.  1531*(NS/NSN)*(NS/NSN)-0.  9535*(NG/NGN)*(NS/NSN) 

$  +1. 5745*(NG/NGN)*(NG/NGN)+0. 5181*(NS/NSN) 

$  -1.  6232*(NG/NGN)+0. 46015 

c 

A22=.  056875*(NS/NSN)-1.  3166*(NG/NGN)+. 3962 
c 

A23=EXP(0. 92011*(NS/NSN)-4. 2549*(NG/NGN)+6. 2290) 
c 

A31=0.  0 
A32=0. 0 
A33=-10. 0 
B11=0. 0 
B12=0. 0 
B21=0. 0 
B22=-14. 17 
B31=10.  0 
B32=0. 0 
c 

c  compute  plant  input  offset 
DMF=MF-MFI 
DQL=QL-QLI 

DNGD0T=A 1 1*DNG+A 12*DNS+A 1 3*DE 
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DNSD0T=A21*DNG+A22*DNS+A23*DE+B22*DQL 

DED0T=A31*DNG+A32*DNS+A33*DE+B31*DMF 

c 

c  compute  integral  of  the  rates 

c  use  rectangular  integration  methos  with  a  time  step  of  0. 001  sec 
DNG=DNG+DNGDOT*0.  001 
DNS=DNS+DNSDOT’V0.  001 
DE=DE+DED0T*0.  001 
c 

c  compute  the  state  variables 
NG=NG+DNG 
NS=NS+DNS 
E=E+DE 
c 

100  CONTINUE 
c 

STOP 

ENT) 
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APPENDIX  B.  C  VERSION  OF  REAL  TIME  SIMULATOR 


This  program  computes  compressor  speed,  compressor  outlet  pressure  and 
compressor  air  mass  flow  rate. 


#  include  <stdio. h> 

#  include  <math.  h> 
main  ( ) 

/*  establish  starting  point*/ 
int  n,ct,t; 

double  ng,ngn,ns ,nsn, e,mf i,qli,mf ,ql ,z; 
double  dngjdns ,de , all , al2 , al3; 
double  a, b , c , a2 1 , a31 , a32 , a33 , a22 , a23; 
double  b22,b31; 

double  dmf ,dql jdngdotjdnsdot, dedot; 

double  p2n,p2nn,mn,p2,mdot; 

ng=20220. 0; 

ns=1510.  0; 

e=79. 0; 

mfi=79.  0; 

qli=65. 0; 

z=0.  0; 

t=0; 

/*  initial  mf  and  ql  values  */ 
mf=79.  0; 
ql=65. 0; 

/*  initial  offset  values  */ 

start: 

ct=0; 

dng=0.  0; 

dns=0.  0; 

de=0.  0; 

/*  normalizing  values  */ 
ngn=26000. 0; 
nsn=1750.  0; 

/*  simulation  loop  */ 

n=100; 

while  (n) 

ct=ct+l; 

all=-l.  0*exp((-0.  6993*(ns/nsn))+(5.583*(ng/ngn))-3.  2433); 
al2=-l.  0*exp(C-2.  8415*(ns/nsn) )+( 7. 9978*(ng/ngn))-4.  4662); 
al3=exp((-0.4579*(ns/nsn))+(l.  189*(ng/ngn) )+6. 8305); 
a=(.  1531*(ns/nsn)*(ns/nsn) ) -( . 9535*(ng/ngn)*(ng/ngn) ); 
b=( 1.  5745*(ng/ngn)*(ng/ngn))+(0.  5181*(ns/nsn) ); 
c=C-l.  6232*(ng/ngn))+0. 46015; 
a21=a+b+c; 

a22=(0. 056875*Cns/nsn))-Cl. 3166*(ng/ngn))+0.  3962; 
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a23=exp((0.  92011*(ns/nsn) ) -(4.  2549*(ng/ngn) )+6.  2290); 

a31=0.  0; 

a32=0.  0; 

a33=-10. 0; 

b22=-14.  17; 

b31=10.  0; 

/*  compute  plant  input  offset  */ 

dmf=mf -mf  i; 

dql=ql-qli; 

dngdot=( al l*dng)+( al2*dns )+( al3*de) ; 

dnsdot=(a21*dng)+(a22*dns)+(a23*de)+(b22*dql); 

dedot=(a31*dng)+(a32*dns)+(a33*de)+(b31*dmf); 

/*  compute  integral  of  the  rates  */ 

/*  use  rectangular  integration  method  */ 
dng=dng+(dngdot*.  000368); 
dns=dns+(dnsdot*.  000368); 
de=de+( dedot*.  000368); 

/*  compute  the  state  variables  */ 

ng=ng+dng; 

ns=ns+dns; 

e=e+de; 

/*  compute  p2  and  mdot  from  state  variables  */ 

p2nn=0. 504-( 1.  44*ng/26000.  0)+(0.  0134*ns/1500.  0); 

p2n=p2nn+(l.  81*(ng/26000.  0)*(ng/26000.  0)); 

mn=-0.  176+( 1.  16*ng/26000.  0)+(0.  022*p2n); 

p2=p2n*l4. 0; 

mdot=mn*2. 36; 

z=(ct/100. 0)+t; 

ql=(26.  0*z)+65.  0; 

mf=(8.  7*z)+79.  0; 

n=n-l; 


t=t+l; 

print f  ("?id  n",t); 
printf  ("/i6.  3f  n",ng); 
printf  ("%2.  4f  n",mdot); 
printf  ("?o3.  4f  n",p2); 

/*  start  over  */ 

mf i=mf ; 

e=mf; 

qli=ql; 

if  (t<10) 

( 

goto  start; 

} 

} 
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APPENDIX  C.  CLIPS  INTERACTIVE  SIMULATOR  C  CODE 


This  program  is  similar  to  the  C  simulator  code  in  Appendix  B  only  the  CLIPS 
interaction  commands  have  been  added. 


//  include  <stdio.  h> 

U  include  <math.  h> 

//  include  "clips,  h" 
main  (  ) 

I 

/*  establish  starting  point*/ 
char  turb[  60]  ,  plant[  60]  ,  surge[  60] ; 
int  n,ct; 

double  ng,ngn,ns ,nsn,e,mfi,qli,mf ,ql,z,t; 
double  dng,dns,de,ali,al2,al3; 
double  a,b, c , a21 , a31 , a32 , a33, a22 , a23; 
double  b22,b31; 

double  dmf , dql , dngdot , dnsdot , dedot; 
double  p2n,p2nn,mn,p2 ,mdot; 
float  rpm,pdis ,pnoz,pin; 

FILE  *input_file; 

FILE  *output_f ile; 

sprintf(turb,"%s" ,"turb.  dat"); 

spr intf (plant , "/os"  ,  "plant,  txt" ) ; 

sprintf(surge,"%s" , "surge,  dp"); 

init_clips( ); 

load_rules( surge) ; 

ng=20220. 0; 

ns=1510.  0; 

e=79.  0; 

mfi=79.  0; 

qli=65. 0; 

z=0.  0; 

t=0.  0; 

/*  initial  raf  and  ql  values  */ 
mf=79.  0; 
ql=65.  0; 

input_file  =  fopen(plant ,"r"); 

/*  initial  offset  values  */ 

start: 

ct=0; 

dng=0.  0; 

dns=0.  0; 

de=0.  0; 

/*  normalizing  values  */ 
ngn=26000.  0; 
nsn=1750.  0; 

/*  simulation  loop  */ 
n=100; 
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while  (n) 

{ 

ct=ct+l; 

all=-l.  0*exp((-0.  6993*(ns/nsn))+(5.  583*(ng/ngn) ) -3. 2433); 

al2=-l. 0*exp((-2. 8415*(ns/nsn))+(7.  9978*(ng/ngn) ) -4.  4662); 

al3=exp((-0.  4579*(ns/nsn) )+( 1. 189*(ng/ngn) )+6. 8305); 

a=( . 1531*(ns/nsn)*(ns/nsn) ) -( . 9535*(ng/ngn)*(ng/ngn) ); 

b=( 1.  5745*(ng/ngn)*(ng/ngn) )+( 0. 5181*(ns/nsn)); 

c=( -1. 6232*(ng/ngn))+0.  46015; 

a21=a+b+c; 

a22=(0. 056875*Cns/nsn))-(l. 3166*(ng/ngn) )+0.  3962; 

a23=expC(0. 92011*(ns/nsn) ) -( 4. 2549*(ng/ngn) )+6. 2290); 

a31=0.  0; 

a32=0.  0; 

a33=-10.  0; 

b22=-14. 17; 

b31=10.  0; 

/*  compute  plant  input  offset  */ 

dmf=mf-mf i; 

dql=ql-qli; 

dngdot=( al l*dng)+( al2*dns )+( al3*de ) ; 

dns  dot=( a2 l*dng ) +( a2  2*dns )+(a23*de)+(b2  2*dq 1 ) ; 

dedot=(a31*dng)+(a32*dns)+(a33*de)+(b31*dmf); 

/*  compute  integral  of  the  rates  */ 

/*  use  rectangular  integration  method  */ 
dng=dng+( dngdot* .  000368); 
dns=dns+(dnsdot*. 000368); 
de=de+( dedot*.  000368); 

/*  compute  the  state  variables  */ 

ng=ng+dng; 

ns=ns+dns; 

e=e+de; 

/*  compute  p2  and  mdot  from  state  variables  */ 

p2nn=0.  504-(l. 44*ng/26000. 0)+(0. 0134*ns/1500. 0); 

p2n=p2nn+( 1.  81*(ng/26000. 0)*(ng/26000. 0) ); 

mn=-0.  176+(1.  16*ng/26000. 0)+(0. 022*p2n); 

p2=p2n*14.  0; 

mdot=mn*2.  36; 

z=(ct/200.  0)+t; 

ql=(26. 0*2)+65.  0; 

mf=(8.  7*z)+79.  0; 

n=n-l; 


t=t+.  5; 

output_file  =  fopen(turb,"w"); 
fscanf  ( input_file,"/of"  ,&rpm); 
fscanf  ( input_f ile , "%f" j&pdis); 
fscanf  ( input_file,"%f" ,&pin); 
fscanf  ( input_file,"%f"  ,6£pnoz); 
fprintf  (output_file,"%6.  4f  n",rpm); 
fprintf  (output_file,"%6. 4f  n"jpdis); 
fprintf  (output_f ile,"%6.  4f  n",pin); 
fprintf  (output_f ile,"%6.  4f  n"jpnoz); 
fprintf  (output_file,"/o6.  4f  n"jng); 
fprintf  (output_f ile,"%6.  4f  n"jmdot); 
fprintf  (output_file,"%6.  4f  n",p2); 
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f close  (output_file); 
reset_ciips( ); 
assert ("start -up"); 
run( -1); 

/*  start  over  */ 

mf  i=mf; 

e=mf; 

qli=ql; 

if  (t<10.  0) 

goto  start; 
fclose  ( input_f ile); 

1 

usrfuncs( ) 

{} 
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APPENDIX  D.  EMBEDDED  CLIPS  SUBROUTINE  CODE 


This  CLIPS  program  which  will  be  embedded  in  the  main  C  code.  Based  on  inputs 
from  plant  and  model  it  reached  a  diagnostic  control  decision. 


(defrule  open-file 
(start-up) 

=> 

(open  "turb.dat"  data) 

(assert  (read-file))) 

(defrule  read-turb-f ile 

?read-file  <-  (read-file) 

=> 

(retract  ?read-file) 

(assert  (rpm  =(read  data))) 

(assert  (pdis  =(read  data))) 

(assert  (pin  =(read  data))) 

(assert  (pnoz  =(read  data))) 

(assert  (rpm-m  =(read  data))) 

(assert  (air-m  =(read  data))) 

(assert  (pdis-ra  =(read  data))) 

(assert  (computation)) 

(close)) 

(defrule  computation 

?computation  <-  (computation) 

?rpms-m  <-  (rpm-m  ?rpm-m) 

?pnozs  <-  (pnoz  ?pnoz) 

?pdiss  <-  (pdis  ?pdis) 

?pins  <-  (pin  ?pin) 

?pdiss-m  <-  (pdis-m  ?pdis-m) 

?airs-m  <-  (air-m  ?air-m) 

=> 

(retract  ?computation) 

(retract  ?rpms-m) 

(retract  ?pnozs) 

(retract  ?pdiss) 

(retract  ?pins) 

(retract  ?pdiss-m) 

(retract  ?airs-m) 

(assert  (h-rpm-m  =(+  ?rpm-m  350.0))) 

(assert  (1-rpm-m  =(-  ?rpm-m  350.0))) 

(assert  (pr  =(/  ?pdis  ?pin))) 

(bind  ?pr-m  (/  (+  ?pdis-m  ?pin)?pin)) 

(assert  (h-pr-m  =(+  ?pr-m  .035))) 

(assert  (1-pr-m  =( -  ?pr-m  .035))) 

(assert  (air  =(*  15.0706  (sqrt  (/  (-  ?pin  ?pnoz)  ?pin))))) 

(assert  (h-air-m  =(+  ?air-m  .06))) 

(assert  (1-air-m  =( -  ?air-m  .06))) 

(bind  ?t-rhs  (*  (-  (*  (sqrt  (/  (-  ?pin  ?pnoz)  ?pin))  11.354)  .7602)  ?pin)) 
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(bind  ?t-lhs  (-  ?pdis  ?pin)) 

(assert  (air-m  ?air-m)) 

(assert  (pr-ra  ?pr-ra)) 

(assert  (t-rhs  ?t-rhs)) 

(assert  (t-lhs  ?t-lhs))) 

(defrule  rpm-check 
(h-rpra-ra  ?h-rpm-m) 

(1-rpra-ra  ?l-rpin-m) 

(h-pr-m  ?h-pr-m) 

(1-pr-m  ?l-pr-m) 

(rpm  ?rpm5£:  (>=  Th-rpm-m  ?rpm)&:  (>=  ?rpm  ?l-rpm-m)) 

(pr  ?pr&:  (>=  ?h-pr-ra  ?pr)&:  (>=  ?pr  ?l-pr-ra)) 

=> 

(fprintout  t  "plant  within  specification  "crlf)) 

(defrule  pr-low 

(h-rpra-ra  ?h-rpin-ra) 

(1-rpra-ra  ? 1-rpra-ra) 

(1-pr-ra  ?l-pr-m) 

(h-air-m  ?h-air-ra) 

(rpm  ?rpra&: (>=  ?h-rpra-m  ?rpra)&; (>=  ?rpm  ?l-rpm-ra)) 

(pr  ?pr5c:  (>  ?l-pr-ra  ?pr)) 

(air  ?air6c;  (>  ?air  ?h-air-m)) 

=> 

(fprintout  t  "choke  potential  if  trend  continues"crlf ) ) 

(defrule  pr-high 

(h-rpra-m  ?h-rpra-ra) 

(1-rpra-m  ?l-rpm-ra) 

(h-pr-ra  ?h-pr-ra) 

(1-air-ra  ?l-air-ra) 

(rpm  ?rpra&: (>=  ?h-rpra-ra  ?rpra)&:(>=  ?rpra  ?l-rpra-m)) 

(pr  ?pr5c:(>  ?pr  ?h-pr-m)) 

(air  ?air&: (<  ?air  ?l-air-ra)) 

=> 

(fprintout  t  "surge  control  need  possible"cr If ) 

(assert  (surge  test))) 

(defrule  surge-test 
(surge  test) 

(t-rhs  ?t-rhs) 

(t-lhs  ?t-lhs&:(>  ?t-lhs  ?t-rhs)) 

=> 

(fprintout  t  "surge  control  activated"crlf ) ) 

(defrule  surge-test-f ail 
(surge  test) 

(t-rhs  ?t-rhs) 

(t-lhs  ?t-lhs&;(<=  ?t-lhs  ?t-rhs)) 

=> 

(fprintout  t  "out  of  specs; not  enough  to  activate  controlsystem"crlf ) ) 
(defrule  rpm-greater 
(h-rpm-m  ?h-rpm-ra) 

(h-air-m  ?h-air-m) 

(1-air-m  ?l-air-m) 

(rpm  ?rpra&;(>  ?rpra  ?h-rpra-ra)) 

(air  ?air&:(>=  ?h-air-m  ?air)&:(>=  ?air  ?l-air-m)) 

=> 

(fprintout  t  "surge  control  need  possible"cr If ) 
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(assert(surge  test))) 

(defrule  rpm-greater-low-air 
(h-rpm-m  ?h-rpra-iii) 

(1-air-m  Tl-air-m) 

(h-air-m  ?h-air-ra) 

(rpm  ?rpiii&:  (>  ?rpin  ?h-rpm-ra)) 

(air  ?air£t:(>  ?l-air-m  ?air)) 

=> 

(fprintout  t  "surge  control  need  possible"crlf ) 

(assert  (surge  test))) 

(defrule  rpiii-greater-hi-air 
(h-rpm-m  ?h-rpra-m) 

(h-air-m  ?h-air-m) 

(h-pr-m  ?h-pr-m) 

(air-m  ?air-m) 

(pr-m  ?pr-m) 

(rpm  ?rpm&: (>  ?rpm  ?h-rpm-m)) 

(air  ?air&:(>  ?air  ?h-air-m)) 

(pr  ?pr&: (>=  ?pr  ?h-pr-m)) 

=> 

(bind  ?pr-diff  (-  ?pr  ?pr-m)) 

(bind  ?slopes  (/  ?pr-diff  (-  ?air  ?air-m))) 

(assert  (slope-check  ?slopes))) 

(defrule  slope-check- low 

(slope-check  ?slopes&: (>=  .7534  ?slopes)) 

=> 

(fprintout  t  "plant  out  of  specs,  no  surge  danger"crlf ) ) 
(defrule  slope-check-high 

(slope-check  ?slopes&: (<  .7534  ?slopes)) 

=> 

(fprintout  t  "surge  control  need  possible"crlf ) 

(assert  (surge  test))) 

(defrule  rpm -great er -hi -air- low-pr 
(h-rpm-m  ?h-rpm-m) 

(h-air-m  ?h-air-m) 

(h-pr-m  ?h-pr-m) 

(rpm  ?rpm&: (>  ?rpm  ?h-rpm-m)) 

(air  ?air£c:  (>  ?air  ?h-air-m)) 

(pr  ?pr6c:  (>=  ?h-pr-m  ?pr)) 

=> 

(fprintout  t  "choking  potential  if  trend  continues"cr If ) ) 
(defrule  rpm-less-air-equal 
(1-rpm-m  ?l-rpm-m) 

(h-air-m  ?h-air-m) 

(1-air-m  ?l-air-m) 

(rpm  ?rpmSc:  (>  ?l-rpm-m  ?rpm)) 

(air  ?air&;  (>=  ?h-air-m  ?air)&: (>=  ?air  ?l-air-m)) 

=> 

(fprintout  t  "plant  in  no  danger  of  surging"cr If ) ) 
(defrule  rpm-less -hi-air 
(1-rpra-m  ? 1-rpm-m) 

(h-air-m  ?h-air-m) 

(rpm  ?rpm6c:  (>  ?l-rpm-m  ?rpm)) 

(air  ?air&:(>  ?air  ?h-air-m)) 
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(fprintout  t  "chocking  potential  if  trend  continues"crlf ) ) 
(defrule  rpm-less-low-air 
(1-air-m  ?l-air-m) 

(1-rpm-m  ?l-rpm-m) 

(pr-m  ?pr-m) 

(pr  ?pr) 

(air-m  ?air-m) 

(rpm  ?rpm6c:  (>  ?l-rpm-m  ?rpm)) 

(air  ?air5c:  (>  ?l-air-rn  ?air)) 

=> 

(bind  ?pr-dif  (abs  (-  Tpr-m  ?pr))) 

(bind  ?slope  (/  ?pr-dif  (-  ?air-m  ?air))) 

(assert  (slope  ?slope))) 

(defrule  low-slope 

(slope  ?slope6c:  (>  .7534  ?slope)) 

=> 

(fprintout  t  "surge  control  need  possible"crlf ) 

(assert  (surge  test))) 

(defrule  high-slope 

(slope  ?slope&:(<=  .7534  ?slope)) 

=> 

(fprintout  t  "plant  out  of  specs;  no  surge  danger"crlf ) ) 
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